Product testing requires a large number of tests to be run, and each test result must be stored. For example, one software product in development can require that up to 500,000 tests be run each night. It is of great importance that the developers track and manage regressions in the product.
If each test result were to be stored in a separate record in a database, then we would expect in excess of 150 billion test records (or rows) to be generated in the test database each year. A database with this many records has a number of logistical problems, including search times that are prohibitively high. Further, back-up times and disk space usage are sub-optimal, the database user experiences slow response, as portions of the database are paged in and out of memory, and fixing errors and handling missing records is difficult. Additional problems arise if the database is to be used over a WAN instead of a LAN.
As a result, test departments often “throw away” test results for previous product releases, and sometimes even for tests run only a few weeks ago. This can cause real problems when several different versions of a product are maintained. Similarly, throwing away the history of previous tests is not conducive to the quality process.
There is, therefore, a need in the art for a system, process and computer program product for creating a manageable database containing all the results of the automated test runs, and for other purposes.